Don't forget to update https://github.com/apache/maven-scripting-plugin/blob/master/src/site/markdown/script-context.md

I'm going to close this one as I consider this a security vulnerabilty. The introduction of servers with exposed username/password means you can easily extract the credentials from the system it is running on.

@rfscholte will you also prevent using any mojo? It is the same security level. Without that this plugin is not that helping in most cases IMHO (no easy website custo/generation), no CI/CD etc...
Worked around this lack by using exec plugin and a custom maven deceypter - it is just 100LoC but the security point is clearly not accurate for any mojo since they all have access to it and they are all - script or not - part of the build. Preventing a script not in the project is a thing but not all other cases technically speaking.

You could also add:

         bindings.put( "pluginDescriptor", pluginDescriptor );
         bindings.put( "mojoExecution", mojoExecution );

from #7 if you think it adds any benefits.
Needs a rebase and spotless:apply either way.

@bmarwell this is true but this is also something the script somehow know in the context of a project. What would be more useful is a replacement for plexus container to lookup any potentially needed bean or a loose coupling like in exec:java (constructor injection runnable case) but my suspicion is maven (4) misses a container handler for these cases.

Re-opened for new evaluation

A big -1 here

@cstamas any rational behind and proposal to solve the related issue (enable to do proper resolutions from the script)?

This is a matter of principle, and IMHO, vision.

Plugins like these are like "swiss knives" and allows hacking, in effect, like Ant or other tools allow it (and makes Maven hackable just like one would do with Ant).

Maven IMHO should be more like "set of Un*x tools" instead: set of battle tested (but also simple) plugins, that do few things, but do them well.

If someone is akin for "swiss knife" plugins like these, for me is clear sign that they want to even widen their "hacking", that is IMHO another sign, they should be using Gradle, Ant or whatever else. Maven is a declarative build system.

And I did not even mention the reasons Robert brought up.... (plus multitude of other reasons).

This is a matter of principle, and IMHO, vision.

Plugins like these are like "swiss knives" and allows hacking, in effect, like Ant or other tools allow it (and makes Maven hackable just like one would do with Ant).

Maven IMHO should be more like "set of Un*x tools" instead: set of battle tested (but also simple) plugins, that do few things, but do them well.

If someone is akin for "swiss knife" plugins like these, for me is clear sign that they want to even widen their "hacking", that is IMHO another sign, they should be using Gradle, Ant or whatever else. Maven is a declarative build system.

And I did not even mention the reasons Robert brought up.... (plus multitude of other reasons).

This is also already possible in the exec plugin, and no one said this was a vuln (see Romains comment). Then, this would mean you need also get rid of exec-plugin.

Then, what about the requirements history?

Why was this plugin released in the first place? There could have been a vote against it at that time?

It is not all black or white of course.

We do need some "backdoors" open, for case of "emergency", if no plugin exists that does what you need. But if you google it, you will see the trend: "use hack in maven, but if you need it too often, write a plugin for it" tendency. And we must not lose this.

This is why originally writing maven plugins was possible using ant scripts and beanshell as well. Beanshell, Ant script, they were all there to lower the plugin authoring barrier, BUT, those were plugins, they used plugin API, had descriptors, etc, so any future thing like build avoidance, incremental build (real one, not what we have today), etc. could rely on them.

Problem is when "hacks" remain hacks, or worse, when "hacks become pattern" (of using some "special" (backdoor) plugin). So if you have ant/exec plugin in build, it is okay, as long as you do not stick with it. But in our case, I see pattern of building some "library of hacks" on top of these, that makes ANY of these "solutions" non reusable, non shared, not maven plugins

If you need something special, hack it once. But second time write a plugin for it. Period.

In short, we do need "stepping stone" plugins (hacks, like exec, ant plugins) to solve some ad-hoc scenarios, BUT these are stepping stones, in a sense, if pattern is repeated, they should be made into reusable plugins ultimately, while I see no intention of that happening here. In contrary, I see quite the opposite intent.

@cstamas I'm on the camp to enable people to do what works for them, for me maven key is dependencies and it must stay static, rest (build pipeline) already broke maven original design and convention and it is bad to need to create a module/project for a build need so I'm clearly keen to see this kind of thing happening. No strong push from me there since I moved to exec and some companions but think it is sane.

I'm somewhere between the lines here. If you have a common use case, a dedicated plugin is probably a better solution compared to the exec-, antrun-, or scripting-plugin.

I'll say let's skip this pr for now... There's also #7 FWIW.
If more people need such a backdoor, we can visit this and #7 again.

Resolve #44

There are some pretty heavy -1's on this, and no approvals so I'm going to close this one as rejected.

Tempted to say it should be reopened or another fix be proposed cause as of today the scripting plugin stays hard to use without that making exec superseeding scripting plugin.

For security point: it is mainly convenience since everything is available while the eval impl doesn't fork.

FTR exec plugin supports it out of the box but requires to compile something before which isnot as neat as scripting plugin (a module/project or the main module if the build classes are excluded in jar plugin): https://github.com/mojohaus/exec-maven-plugin/blob/master/src/main/java/org/codehaus/mojo/exec/AbstractExecJavaBase.java#L518.

Lets keep it open for future. Maybe we will have more voiced or something will change in mean time.
I have no strong opinion which way to go - similar with Gradle it's possible to write any code and access credentials in Groovy

Hi guys, can you review it again?
We just got a release and this 4 yo PR missed it.
All the -1 I see are "it is bad" but we do these bad things in pretty much all plugins so tempted to say it doesn't hurt more and ultimately we delegate the "bad" impact on the user land only.
I'm pushing it a bit because it enables so much cases and solve all the groovy/external-scripting issues by using java which is a big pro.
In current form we just need to hack maven to grab the session by reflection which is worse IMHO.

Tests are failing. Fixing that would be required for review. I don't have a particular opinion on this, but I note that other people whose opinion I respect are all negative about this, so I don't hold out high hopes here. It's uncommon for a PR to get multiple informed -1 votes so it's probably worth paying attention to.

Ok so build should be green now :)

@cstamas while I agree on your phrasing I also met too often these cases (a lot around living doc and living deployments, rarely on the build phase itself - the side note there is it is often specific to the infra/project) to be happy with "write a plugin" in current form today and we'll not solve plugin entry cost until at least maven 6 I think so can you revise your -1 to at least a +0?

Hi there! I’ve been following this PR and I think exposing the MavenSession instance is a crucial addition for this plugin. It would significantly increase the scripts' capabilities by allowing access to project properties, settings, and the reactor state in a straightforward way.

I personally prefer this plugin over others like gmavenplus due to its simplicity and 'Maven-native' feel. Is there anything

I can help with to move this forward? It would be great to see this merged and released. Thanks for the effort!